\part{Patterns of Managing}
\section{Controlling Projects}
Software projects have to face change when demands on the software itself and
development techniques alter. Demands on software and its production process
are always changing. Gerald M. Weinberg, in his early 90s view, displays the
rapid change regarding the evolution of word processors, comparing word
processors of the mid eighties with the standard at that time. This analogy
could be mapped on the rapid change of distributed environments like Service Oriented Architectures or agile software development techniques in the past years.\\
These heavy changes describe the habit of software and software development as
``\textit{moving targets}''. Weinberg uses the moving targets analogy with birds flying through the skies and one trying to shot them down. As well as to control a software project you'll have to predict the movement of targets to meet your demands and restrictions. There are basically two different control models trying to provide solutions for this matter.
%In which organizational patterns do the following models occur Software quality and productivity as moving targets Software is constantly changing Swarm of birds analogy. Try to hit one. Even though Pattern 2 managers try to forbid their employees of being absent due to influenza, there is no option to do so.
\subsection{Aggregate Control Model}
The \textit{Aggregate Control Model} is a classic brute force approach. The project controller is trying to start random activities that are more or less blind and driven by actionism. This model could be described as a duck hunt with a shot gun. Multiple bullets are fired at once, with the acceptance of a low but satisfying success rate.
\begin{figure}[H]
\begin{center}\pgfimage[width=0.3\textwidth]{Grafiken/aggregate}\end{center}
\caption[Aggregate Control Model - Shot gun]{Aiming with a shot gun}
\end{figure}
In the scope of software development a shot gun would be the simultaneous starting of multiple projects, all with different developers, tools and parameters, that are trying to meet a specific set of requirements or conditions. When one project meets these requirements to a satisfying degree, all other projects are stopped and the corresponding work invested in those dropped projects is lost.

\subsection{Feedback Control Model}\label{fbs}
If the Aggregate Control Model was the picture of a heavy loaded, dumb and brute force act of shooting blindly on targets, the \textit{Feedback Control Model} would be the art of aiming with a one bullet sniper rifle. Feedback Control Models take the systems dynamics into respect and try to predict its future movement.
%A more precise approach since the movement and dynamics of a system are respected and put into consideration. Compare what is planed, bring system's behavior closer to the plan.
\begin{figure}[H]
\begin{center}\pgfimage[width=0.3\textwidth]{Grafiken/feedback}\end{center}
\caption[Feedback Control Model - Rifle]{Aiming with a rifle}
\end{figure}
Feedback Control Models offer the ability of early and effective
\textit{feedback}. This means, actions are taken or respected that will move the
system's state into a specific direction, which means the direction the system moves by it's own dynamics.\\

The basic principles are the comparison of the planed state and the actual
state. Subsequently the controller tries to bring the actual state closer to
the desired state according to the \textit{Feedback Control Steps}
described below:
\begin{itemize}
\item Plan what should happen:
\textit{D}
\item Observe what significant things are really happening:
\textit{A}
\item Compare the observed with the planned:
\textit{D - A}
\item Take actions needed to bring the actual closer to the planned:
\textit{A}$\to$\textit{D}
\end{itemize}
\newpage
\section{Diagram of Effects}
\subsection{Motivation}
Systems describe natural relationships in reality. Almost all of these systems
are therefore not linear and not that easy to predict. Most Systems dynamics
ahead of Pattern 1 are fluid and not deterministic either. If the systems
reality isn't pointed out, managers take wrong decisions and steer the project
to explosion or collapse.\\
In a software project different parameters influence the state of a project. If
these parameters are not defined and analyzed, projects will fail in most cases.
Diagrams of Effects try to examine these complex relationships and put them
into a common understandable notation, that will be described in this section.
\subsubsection{Scaling Fallacy}
Even though systems have a non deterministic nature, some managers believe that they're able to predict the system's state by interpolating values with simple arithmetic rules. Believing that predicting systems states is as easy as 1+1 and it's equating state is 2, is described as the \textit{Scaling Fallacy}.\\

To keep the example and take to advance of the Feedback Control Steps introduced in section \ref{fbs}: If \textit{D} is 2 and \textit{A} is 1, if then \textit{D-A} might be 1, achieving (\textit{A$\to$D}) the desired state (\textit{D}) by adding 1 to the actual (\textit{A}) might not work and the system might be therefore not linear.\\
The Scaling Fallacy is best described with:
\begin{center}\textit{Believing that large systems are like small systems, just bigger.}\end{center}
Adding people to a late project does not necessarily mean, that the project
finishes faster (see \ref{Brooks Law} \textit{Brooks's law}), like it would be
in a one man coding project on Pattern 1 level. Within more complex projects,
as found in Pattern 2 organizations, adding new people in a late state of the
project would result in additional work due. Resulting from increased
learning effort to the new and old employees.

\subsection{Back Problems Example}
On of Weinberg's key elements is the Diagram of Effects, which will be introduced by a very common and easy to understand example in the following section.\\

Imagine your personal ``system of physical health'', gaining weight will lead you to back problems, while gaining weight will also lower your motivation of doing exercises. Therefore, less exercise will lead to even more back problems. With less back problems your motivation for doing more exercises will rise.
\begin{figure}[H]
\begin{center}
\pgfimage[width=0.6\textwidth]{Grafiken/backProblems}
\caption[Diagram of Effects - Back Problems Example]{Back Problems Example}
\label{backProblemsExample}
\end{center}
\end{figure}
According to this example there are these feedback relationships:
\begin{itemize}
  \item More weight $\to$ More back problems.
  \item More weight $\to$ Less exercise.
  \item Less exercise $\to$ More back problems.
  \item Less back problems $\to$ More exercise.  
\end{itemize}
The Feedback Control models tries to visualize such relationships like in figure \ref{backProblemsExample}. See the next section for a closer view on the notation of the used elements in this diagram.
\newpage
\subsection{Notation}
\subsubsection{Nodes}
A node stands for a measurable quantity. There is no specification which value such a measurable quantity has, it can be either a value or a conceptual measurement. Values that could be measured but not intended to do so.
\begin{figure}[H]
\begin{center}
\pgfimage[width=0.3\textwidth]{Grafiken/cloud} 
\caption[Diagram of Effects - Actual Measurement]{Actual Measurement}
\end{center}
\end{figure}
The form of an ellipse shows that measurement is currently made, like weight
displayed on a scale. From this point on all other measurements can be predicted or calculated depending on the actual weight. \begin{figure}[H]
\begin{center}
\pgfimage[width=0.3\textwidth]{Grafiken/ellipse}
\caption[Diagram of Effects - Measurement being made]{Actual Measurement being made}
\end{center}
\end{figure}
The only difference between these two nodes is that the ellipse visualizes an actual measurement, instead of an abstract measurement that would be taken in the future or has been taken in the past.
\newpage
\subsubsection{Connectors}
\begin{figure}[H]
\begin{center}
\pgfimage[width=0.4\textwidth]{Grafiken/pfeilOhneSchrift}
\caption[Diagram of Effects - Positive feedback]{Positive Feedback}
\end{center}
\end{figure}
Positive connectors represent an enforcing feedback from one node to another. With such an arrow it is indicated that if ``Weight'' moves in one direction ``Back Problems'' move in the \textbf{same} direction.
\begin{figure}[H]
\begin{center}
\pgfimage[width=0.4\textwidth]{Grafiken/pfeilNegOhneSchrift}
\caption[Diagram of Effects - Negative Feedback]{Negative Feedback}
\end{center}
\end{figure}
Indicated with a grey dot are negative feedbacks. The same logic as for the
positive feedback are applied here, except that if ``Weight'' moves in one direction, ``Back Problems'' move in the \textbf{opposite} direction.\\\\ These two connectors only differ in the positive and negative influence on the target node. There is no specification about the value and the additive or subtractive effect on the target node.
\subsubsection{Human Decision Points}
\begin{figure}[H]
\begin{center}
\pgfimage[width=0.35\textwidth]{Grafiken/managementArrowsOhneSchrift}
\caption[Diagram of Effects - Human Decision Points]{Human Decision Points}
\end{center}
\end{figure}
Human Decision Points are pointed out with a square in their middle. Weinberg describes this as a non-natural form, like management decisions are less natural givenness and more human made decisions.\\\\
See page \pageref{hdp} ``\textit{\ref{hdp} \nameref{hdp}}'' for detailed information.